1. Technical Field
The present invention generally relates to computer systems and in particular to connection pooling management architecture in computer systems.
2. Description of the Related Art
The connection pooling management structure using a common application programming interface (API), such as Java Database Connectivity (JDBC), describes a standard interaction among an application, an application server, and a database driver. The application can request a connection from a data source using the application server. The application server may in turn either (i) return a cached connection from the application server's own connection pool module, or (ii) get a new connection from a connection pool data source using the database driver. Database drivers are available for most database platforms so that applications can invoke the API to retrieve the information stored in a database. The common implementation of this dichotomy of data sources, connection pool modules, and connection pool data sources is the homogeneous connection pooling model, which naturally treats the data source and the connection pool data source as one and the same. Moreover, the homogenous connection pooling model provides only one connection pool module per data source (i.e. a 1:1 correspondence between the data source and the connection pooling data source) and does not support connections to be cached across multiple data sources having different data source properties. Therefore, the homogeneous connection pooling model does not exploit the full potential of the connection pooling management structure, especially when those multiple data sources represent the same underlying database server with only some different property settings.
Furthermore, as described by the connection pooling management structure using JDBC, the application should not see any difference between the data source that is accessed with connection pooling implementation and the data source that is not accessed with connection pooling implementation. Stated differently, the application should always receive a “clean” connection, whose connection attributes match the data source properties specified on the data source where the connection originates from. However, under the homogeneous connection pooling model, the connection is taken (or “reused”) from the connection pool module of an application server without any cleanup of the connection attributes of the connection from previous reuses of the connection. Instead, special registers and global temp tables from the previous use of the connection remain in effect for the new use of the connection.
To alleviate this problem of an unclean connection, the application server often needs to impose a constraint such that data source properties cannot change for the connection pool module. Despite the imposition of these constraints, the application may still encounter the problem of an unclean connection if the special registers and global temp tables are set through runtime interfaces rather than as data source properties. Under such circumstance where the special registers and global temp tables are set through runtime interfaces, the application has to perform the cleanup after the application is done using the connection. The above scenario provides an extra burden and overhead for the application, since the application must insert code to reset the application's own special registers and global temp tables, such that the values of the data source properties are properly passed and there are no inconsistencies between a database server and the database driver.